[00:01.100 --> 00:05.840]  Hi, I'm Jake LaBelle, and my talk today is going to be on finding surrogate chains on a mainframe.
[00:07.120 --> 00:10.680]  So, who am I? I'm a security consultant at F-Secure.
[00:11.760 --> 00:14.680]  Technically associate, but sounds a bit shit, so...
[00:15.820 --> 00:19.960]  I've been on a couple mainframe jobs, so I'm not an expert by any means.
[00:20.020 --> 00:25.200]  I'm currently streaming from Basingstoke, UK, which is in Vegas, but what can you do?
[00:25.440 --> 00:29.400]  And I was going to put a picture here, but just look to the right, and yep, there I am.
[00:31.380 --> 00:37.220]  So, before I go into my tool that I've created, I'll just do a quick high-level introduction to ZOS,
[00:37.220 --> 00:40.360]  which is the operating system that you find on most mainframes.
[00:41.400 --> 00:49.260]  One of the major differences between Linux, Windows, and ZOS is that ZOS has datasets.
[00:49.440 --> 00:55.260]  So, for example, here it's user01.rexlib, and one thing to know about it is it's a flat file system,
[00:55.260 --> 01:00.380]  so there's no folders, but normally how it works is that you'll have your high-level qualifier
[01:00.440 --> 01:09.100]  which is normally the owner first, so user01, and then .something, .something, blah, blah, blah.
[01:09.460 --> 01:14.700]  And you have apostrophes around datasets. This indicates that it's an absolute path.
[01:14.700 --> 01:21.280]  In all of my Gator program, I have apostrophes around every single dataset because it's just easier.
[01:21.680 --> 01:28.020]  You can also have partitioned datasets, where user01.rexlib is the dataset,
[01:28.020 --> 01:32.580]  but then you can have multiple members in that dataset. So, for example, in this one it would be hello.
[01:32.960 --> 01:41.940]  And the picture below is just a picture of DSList, which shows all the datasets of a high-level qualifier of IBM user.
[01:44.620 --> 01:51.120]  So, my program is mostly written in Rex, which is a scripting language like Python.
[01:51.460 --> 01:54.900]  It has a couple slightly unique functions, though.
[01:54.900 --> 01:59.720]  So, one of them is address, which lets you run a program in another program.
[01:59.720 --> 02:09.480]  So, this is running listDSD in TSO, and the output of that you can store using something called outtrap,
[02:09.480 --> 02:16.740]  which you will then put all the output of that TSO command into a stem variable, which is basically an array.
[02:17.880 --> 02:22.500]  So, another language that's used is the JCL, which is a job control language.
[02:22.500 --> 02:30.540]  It's a batch job, though, so when you submit a JCL, the JCL is then run at some point by the mainframe.
[02:30.760 --> 02:37.660]  And on the first line of every JCL you have the job card, which has the title of the job and a couple of other parameters.
[02:37.660 --> 02:45.760]  So, for example, this will notify the user after it's run, and it will also store it in the spool.
[02:47.600 --> 02:55.040]  So, in my program, all of the JCLs that I have are embedded inside Rex scripts.
[02:55.360 --> 03:00.580]  And so, this one, for example, it will queue all of the lines of the JCL.
[03:00.580 --> 03:04.100]  It will then use outtrap to concatenate those lines and then submit them.
[03:04.140 --> 03:12.960]  The reason why I use this in a Rex script is because you can then parse arguments easier, and you can then have a more dynamic JCL.
[03:14.700 --> 03:23.000]  So, one of the major subsystems on ZOS is OMVS, and it's a Unix subsystem.
[03:23.000 --> 03:27.500]  And it's kind of like the WSL Windows subsystem for Linux.
[03:27.500 --> 03:33.160]  However, there's no segregation between the two parts.
[03:33.180 --> 03:40.320]  So, there's no segregation between TSO and OMVS, TSO being the main part of where you log into the mainframe.
[03:40.320 --> 03:45.600]  So, on TSO, you can run OMVS commands, and on OMVS, you can run TSO commands.
[03:45.600 --> 03:49.120]  So, if you have access to one, you basically have access to the other.
[03:49.700 --> 03:58.440]  And the security of OMVS, so for example, what would be slash etc slash sudoers, is managed by RACF.
[03:58.560 --> 04:03.040]  And RACF is Resource Access Control Facility.
[04:03.040 --> 04:17.180]  And this can handle different types of resources, so for example, datasets, surrogates, or as mentioned before, the OMVS resources.
[04:17.180 --> 04:20.320]  So, for example, superuser would be in there.
[04:21.840 --> 04:29.380]  So, each resource has an owner, and they have alter access, so basically complete access to the resource.
[04:29.380 --> 04:37.780]  You can also set a UACC, which is how much access that just any random user has to the resource.
[04:37.780 --> 04:40.520]  You can also permit other users to have access.
[04:40.520 --> 04:42.980]  So, there's four different types of access you can give.
[04:42.980 --> 04:49.460]  It's execute, read, update, and alter, and they do what they sound like they do.
[04:49.940 --> 04:57.100]  One other special attribute you can give to a user is special.
[04:57.100 --> 05:06.460]  Special means that you basically have alter access to every single resource, which you can think of as being like having roots.
[05:07.320 --> 05:13.380]  One of the main classes in ZOS is surrogate, and there's a couple different types of these.
[05:13.380 --> 05:26.060]  So, we have star.submit, so for example, userid.submit, so user01.submit would mean if you had read access to this, you could submit a JCL as user01.
[05:26.060 --> 05:35.320]  There's also bpx.serve.userid, so for example, bpx.serve.user02 means you can run a su command as that user.
[05:35.800 --> 05:42.900]  There's also dfh.start.userid, and this just means you can run a Kix transaction as that user.
[05:42.900 --> 05:56.840]  I don't use dfh.start in my program, but maybe in the future.
[05:58.980 --> 06:03.740]  So, one thing that you'll find on mainframes are surrogate chains.
[06:03.740 --> 06:10.340]  The reason why these occur is because there's lots of users, and no one knows what all of them are for.
[06:10.340 --> 06:17.200]  So, for example, I was added as a user on a pentest job, and 20 years later, someone's probably going to ask,
[06:17.200 --> 06:20.760]  who is this Jake character, and why does he have access to these things?
[06:20.760 --> 06:25.860]  No one's going to know, and no one's going to delete it, because maybe it'll break something.
[06:26.120 --> 06:30.120]  And that also turns to the other thing, where mainframes have been running for decades.
[06:30.280 --> 06:37.820]  It's one of their major selling factor, so the person who added me is probably going to be long gone before the next person even looks at me.
[06:37.820 --> 06:45.820]  So, a surrogate chain is where, for example, user01 has read access to a surrogate class on user2,
[06:45.820 --> 06:50.560]  and user2 has read access to a surrogate on user3.
[06:51.080 --> 06:57.060]  So, in this case, user01 practically has access to everything that user3 has.
[06:57.460 --> 07:03.880]  And the way you can list what access, what surrogates you have, you can run a command rlist surrogate star.
[07:03.880 --> 07:13.760]  However, RACF has a thing where you can only see the protections on a RACF that you have at least read for.
[07:13.760 --> 07:23.040]  So, in this case, user01 would not be able to see that user2 has a read on a surrogate on user3.
[07:23.280 --> 07:28.240]  The other problem is that star.submit is a batch job.
[07:28.240 --> 07:42.140]  So, let's say you wanted to run a REC script that ran the JCL from user1 as a surrogate on user2,
[07:42.140 --> 07:46.420]  and then wanted to, from user2, run a JCL to user3.
[07:46.420 --> 07:51.920]  You can't just run that in one program because it's using a JCL, which, again, is a batch job.
[07:51.920 --> 07:56.240]  So, what you could do is you could manually submit reverse shells one at a time.
[07:56.240 --> 08:03.140]  So, you'd, as user1, find out that you had a user2 surrogate, then you would submit a reverse shell for user2.
[08:03.140 --> 08:08.580]  Then, once you're as user2, you'd list all your surrogates again, and then you'd submit a reverse shell for user3.
[08:08.700 --> 08:14.600]  However, this takes a long time, and there's a lot of users, so this might not even be feasible.
[08:15.680 --> 08:20.200]  Another thing you could do is you could just use a user which has read access to all the resources.
[08:20.200 --> 08:23.960]  So, for example, a special account or an auditor account.
[08:24.580 --> 08:29.740]  Auditor doesn't really... they don't really have read access to these, but they basically do.
[08:31.900 --> 08:36.340]  Then, you could also then use this to find all the surrogate chains.
[08:36.340 --> 08:39.780]  The only problem with this is that you're not going to get a special account.
[08:39.780 --> 08:46.620]  You're definitely not going to get a special account on a pen test, and you probably won't get an auditor account on a pen test either.
[08:47.900 --> 08:57.160]  So, I created a tool. Here's the GitHub link to it, and it allows you to find and exploit surrogate chains.
[08:57.380 --> 09:01.620]  So, the first thing you do with the tool is you run begin.reqs. It gets all the output datasets ready.
[09:01.620 --> 09:09.700]  It gets the Unix file ready, and it adds the current user that you're running it from to the path, and it starts geo.reqs.
[09:10.520 --> 09:18.920]  geo.reqs gets the path that it currently is at, so when you first run it, it would just be the original user.
[09:19.000 --> 09:25.380]  If it's special, if your user that you have is special, it will just stop, because if you have special, you've already won.
[09:25.700 --> 09:28.920]  It will then run plugins.reqs, which I'll explain later.
[09:29.080 --> 09:35.020]  It will list all the surrogates that you have read access to, and then it checks that those surrogates haven't been visited yet.
[09:35.020 --> 09:41.560]  The reason why I had to add this is because I didn't want to have to deal with cycles, and this was the quickest and easiest way to deal with that.
[09:41.660 --> 09:48.980]  So, you won't actually get the whole, I guess, surrogate network, but you will get a chain through them.
[09:50.160 --> 09:59.120]  If it sees that it's a star.submit resource, it will run subm.reqs, and if it sees that it's a bpx.sub.star resource, it will run unixm.reqs.
[09:59.120 --> 10:07.340]  So, subm.reqs just submits a JCL as the surrogate user, which then runs gator.reqs, so then it will continue it on.
[10:08.080 --> 10:11.240]  Unixm.reqs is a JCL which just runs gator.
[10:11.240 --> 10:26.340]  It's moved into OMVS with begin.reqs to slash temp slash unixm, and then gator calls it with bpx batch, with which you run OMVS commands in TSO, and then you do su to that target user.
[10:26.340 --> 10:31.640]  So, plugins.reqs is a list of req scripts to run on each user.
[10:34.380 --> 10:40.600]  There's a number of enumeration scripts you can run. I have three that I have set up already.
[10:40.740 --> 10:51.080]  One of them just lists the user, so this will tell you if they have special, if they have operations, what groups they're connected to, those types of things.
[10:52.780 --> 11:01.160]  I also have one which will just list your access to all of the RACF databases.
[11:01.160 --> 11:07.100]  It's unlikely you'll have anything other than none for this, but, eh, might as well test.
[11:07.100 --> 11:14.940]  If you have read access, it's really good. It lets you unload the database so you can see all the things in the RACF database. Really useful.
[11:14.940 --> 11:26.160]  If you have update or alter, then you can just put yourself in as special, and I have a tool to just write yourself in, but, yeah, they're very unlikely, but if it does happen, hit the jackpot.
[11:26.940 --> 11:33.160]  The other one is it will search all of the APF libraries to see what access you have to those.
[11:33.160 --> 11:38.040]  You can think of APF libraries as kind of like setguid libraries in Unix.
[11:38.040 --> 11:45.720]  It's not really, but if you have update or alter, you can get special, and there's tools out there to do that.
[11:46.700 --> 12:02.600]  Oh, and also, if you have any other scripts you want to add, it's fairly easy to just, it's fairly extensible, just add your own REC script in, and, like, for example, if you have just a Linux script that you have that you can use, you can quickly add that to there.
[12:03.820 --> 12:24.640]  So, to test to see that the program was working properly, I, using an emulated ZOS, created a thousand users, then randomly assigned a couple operators and a couple special users, added a couple of surrogates of each type to each user, and then ran Gator, the test script to generate all of these users on GitHub as well.
[12:24.640 --> 12:44.780]  So, using the output of all the paths that were generated and also the list user command, so here you can see the large squares are operators and the big star is special, shows you all the paths to get to these users.
[12:44.960 --> 12:50.900]  If anyone can think of a better way to show a thousand nodes on a graph, then, yeah, that'd be helpful.
[12:51.740 --> 13:16.940]  I also created a shell macro, so from the user that you ran the Gator from, you can pick any user that's in the path, the surrogate chain, and it will run shell B, that user, it will then keep submitting a JCL, continuously passing on how far along in the target it is, how far along in the path to the target is,
[13:16.940 --> 13:22.480]  and at the end it will submit a catso shell, it's like an interpreter, here's the GitHub link to it by mainframed.
[13:24.300 --> 13:32.300]  I've also just created a bash script which will quickly upload all the rec scripts, it's just quick to set that up.
[13:33.280 --> 13:39.660]  And yeah, that's my tool, and I'll do a quick thing on if you want to get into mainframes yourself.
[13:39.660 --> 13:50.260]  So probably the easiest way is with TK4-, it's based on a 1980s mainframe, MVS 3.8J, it runs on a Raspberry Pi, which is pretty cool.
[13:50.580 --> 14:03.500]  Everything is open source and public domain, pretty cool again. Here's the link to download it, and there's a user guide to just get started, and yeah, here's a picture of it, again, pretty cool.
[14:06.200 --> 14:16.400]  And on there you can install two fairly important things, so you can get Kix, which is a Kix clone, and there's a Moshix guide, I've put the YouTube link to it.
[14:16.400 --> 14:24.720]  And Kix is like web servers, before web servers were cool, so you can test your COBOL scripting.
[14:25.620 --> 14:37.240]  And Rex is just a backported thing that lets you run rec scripts, again, here's the Moshix guide to get it installed.
[14:37.240 --> 14:45.080]  If you can't be bothered to get these installed, I have one with these already installed on my GitHub. TK4-base is what I called it.
[14:45.860 --> 14:56.280]  Another tool to get started on mainframes is Hercules, it's a QPublic license, it's a mainframe emulator, and it's what TK4 uses to run.
[14:56.860 --> 15:08.120]  Now there is an old version of ZOS version 1.10 online, but piracy is bad, so don't do that.
[15:08.120 --> 15:19.060]  But if you do end up getting a ZOS version, there's a GitHub link to mainframes labs, and they're pretty good to get started.
[15:20.320 --> 15:27.960]  And there's a Mattermost community that's fairly good to answer any questions.
[15:27.960 --> 15:34.900]  If you want to ask me any questions, my username is Tadasu, so drop me a message on there and I'll answer.
[15:34.900 --> 15:40.900]  And that's my talk done. Are there any questions?
